home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0827.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.5 KB  |  53 lines
  1. Thus wrote: Dave_Raggett
  2. >Here at Hewlett Packard, we need a way of preventing unauthorised
  3. >access to information, but want to take advantage of the WWW for
  4. >sharing information with colleagues.
  5. >
  6. >Please give me your comments on our proposed solution.
  7. >
  8. >I am working on a solution that makes use of UNIX's established
  9. >security mechanisms and making it easy for non-technical types
  10. >to manage things for themselves without the need to call out
  11. >the support staff.
  12.  
  13. I've thought about implementing something like this, and I think
  14. that's a reasonable starter solution.
  15.  
  16. (I'm sure you know all this already, but I'll mention it anyway...)
  17.  
  18. - If you want more than token security, passwords flying around the
  19.   network in the clear is obviously a Bad Thing.
  20. - Since the data is passed across the net in the clear, disclosure
  21.   protection may or may not be attained; it depends whether this is
  22.   going on a LAN or a WAN or what.
  23.  
  24. Kerberos type models are possible, but I don't think the current HTTP2
  25. standard could work with kerberos (I believe this would require a
  26. fundamental change in the request-response to something like
  27. request-challenge-reply-response, which is a big change.  Or am I
  28. recalling the changes to version 5 incorrectly?)
  29.  
  30. Ultimately, the general solution should be simple enough; since we're
  31. already using MIME mail-like mechanisms for content identification,
  32. once MIME and PEM are made interoperable (standards should be out
  33. soon), you can have signed PEM (or PEM-like) requests and encrypted
  34. responses.  There would be some trickiness, since the headers of the
  35. response message are among what needs to be authenticated.  The bad
  36. part is that PEM isn't here today, and may not be here any time
  37. particularly soon.  But it's obviously the right solution in the long
  38. run, particularly since the certification hierarchy would allow the
  39. kind of legal mechanisms for non-deniability of origin and disclosure
  40. protection that would be highly desirable for, say, a publisher to
  41. make copyrighted works available via WWW for a modest fee.
  42.  
  43. Since I'm already posting to the list, anyone who is in the process of
  44. trying to write a WWW server in perl may wish to glance at a brief
  45. commentary in http://cs.indiana.edu/perl-server/intro.html that I
  46. made; this includes some discussion of the design guidelines involved
  47. in its creation (which are probably rather controversial) and the
  48. code.  It's not code that you can just pop in and run on your machine,
  49. but your friendly neighborhood perl hacker might find it interesting
  50. to look at.
  51.  
  52. - Marc
  53.